Sides represent the players in a game. They also serve as a repository of information shared by units, such as technology and knowledge of the world.
You should first decide how much about the sides will be predefined. If you're doing Eastern Front scenarios, it's very easy; you have Russians and Germans and that's it. If you're doing a science-fiction empire-building free-for-all, you may not have to specify anything more than a random side name generator.
For scenarios and similarly-restrictive games, the game design should create the sides directly, as in this example:
(side (name "Germany") ... (colors "black,gray") ...) (side (name "Russia") ... (colors "red") ...)
Since the initialization machinery allows matching any player with any side, you can get away with being really vague. This will create four sides but not say anything about them:
(side) (side) (side) (side)
If you're going to have predefined units on each side, then you should add an id to each side:
(side 1 (name "Germany") ... (colors "black,gray") ...) (side 2 (name "Russia") ... (colors "red") ...)
Instead of 1 and 2,
you can also use, say, ge and ru;
ids can be either symbols or numbers.
If your game design does not predefine all the sides,
you can define a side library using the side-library variable.
Basically the library is a weighted list of collections of side properties,
each formatted as a side definition.
Xconq will use this library for any player that is allowed in the
game but who does not have a side already, and select a side with
a probability determined by the weights.
Each item in the library will be used up to a limit that can be specified
with each item;
if the library has been exhausted before all the sides have been created,
then the extra sides will just be assigned general defaults
for their properties.
The side library here makes futuristic sides for players, making two of the sides most likely, but allowing others as well:
(set side-library '( (10 (name "Federation") (adjective "Federation") (class "fed")) (10 (name "Klingon Empire") (noun "Klingon") (class "klingon")) (5 (noun "Romulan") (class "romulan")) ((noun "Ferengi") (class "fed")) ((noun "Vulcan") (class "fed")) ))
Note that if the game design limits certain unit types to certain sides, the choice of sides will be more than just a cosmetic issue.
So that you can put upper and lower bounds on the number of sides in your
game, GDL includes the variables sides-min and sides-max.
As you might expect, every game design must allow at least one side.
The upper limit on sides depends on the implementation, but is at least 7.
Large numbers of sides can make a player's life very complicated,
not to mention consuming vast quantities of memory, so you should
try to limit the number of sides as much as possible.
Another important limit is based on the notion of side classes.
Each side can have a side class, and multiple sides can belong to the
same class.
For instance, sides named "Hyperborean" and "Germanic"
could both have class "barbarian".
The value of side classes is that unit types have a property
possible-sides that limits which side class(es)
a type can belong to. This is very important for any game
in which different players should have fundamentally different
sorts of units. To continue the barbarians example, it is basically
impossible for any barbarian side to have even one Roman legion,
whether by construction, capture, or even surrender.
So you can do something like
(add legion possible-sides "roman") ... (side 1 (name "Rome") (class "roman")) (side 2 (name "Germania") (class "barbarian")) (side 3 (name "Hyperborea") (class "barbarian"))
and ensure that Roman legions are always Roman.
Note that players tend to identify with the sides they're playing, so a game should allow for as much personalization as possible. On the other hand, some scenarios derive part of their flavor from predefinitions. For instance, a scenario with sides named "German" and "Russian", with appropriate colors and emblems, doesn't have quite the same feel when players rename them to "Subgenii" and "Simpsons".
A side can have a huge amount of state data, such as the current view. This rarely needs to be included in its entirety; synthesis methods will usually suffice to set view data correctly. Since total security is impossible with a predefined world, setting a side to have only a partial view won't necessarily be useful to keep players from knowing what that world really looks like.